home *** CD-ROM | disk | FTP | other *** search
- From: thp@cs.ucr.edu (Tom Payne)
- Message-ID: <4ebrss$frt@galaxy.ucr.edu>
- X-Original-Date: 27 Jan 1996 00:33:32 GMT
- Path: in1.uu.net!bounce-back
- Date: 27 Jan 96 00:52:24 GMT
- Approved: fjh@cs.mu.oz.au
- Newsgroups: comp.std.c++
- Subject: Re: Throwing an exception from within a signal handler
- Organization: University of California, Riverside Department of Computer Science
- References: <4du0gr$8k8@galaxy.ucr.edu> <4e0moi$4dp@engnews1.Eng.Sun.COM> <4e35jg$k8c@galaxy.ucr.edu> <4e631s$2fg@hawk.hcsc.com>
- X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBFAgUBMQl3UuEDnX0m9pzZAQH8QgF7B3/GzHvDFT0cgqWdCIYjCGp3JrsNqTeT
- hLlQM9iwpOulcQn+s1Dt41qYpaZBQFB3
- =hrns
-
- Bill Leonard (bill@amber.ssd.hcsc.com) wrote:
- : In article <4e35jg$k8c@galaxy.ucr.edu>, thp@cs.ucr.edu (Tom Payne) writes:
- : > If the ABI implementation of signal blocking is missing or has high
- : > overhead, then we can use global flags inside the program to reduce
- : > blocking to setting a bit and reduce unblocking to clearing that bit
- : > and checking whether a deferred signal has arrived (in which case
- : > there is additional overhead to check which signal to process it).
- :
- : Maybe I've missed something here, but wouldn't that code have to appear in
- : every function prologue and epilogue? The only reason for signal blocking
- : (I thought) was that trying to propagate an exception into or through a
- : stack frame that is partially constructed or destroyed is problematic.
- :
- : I certainly wouldn't want code to check (and handle) a signal to be
- : generated in every function prologue! Talk about code bloat!
-
- We need to shrink-wrap critical sections where the stack might be in
- an inconsistent state (prologues and epilogues) against exceptions
- thrown by signal handlers. We can do this by:
-
- 1. setting a flag during such regions,
-
- 2. having the compiler generate PC-range tables telling where
- these sections are,
-
- 3. using some kind of pattern recognition to determine whether
- the interrupted function invocation was in a critical section.
-
- Solution #1 involves at each critical section two writes and a
- conditional jump around a call to a function that throws deferred
- exceptions (as a proxy for the signal handler). Solutions #2 and #3,
- proposed by David Chase, involve no overhead in time, but #2 involves
- some space overhead.
-
- Steve Clamage has raised the question of existing libraries. Under
- solutions #1 and #2, such libraries would have to be recompiled or
- else calls to them would have to be shrink-wrapped for the duration of
- the called function (leading to objectionable latencies if the
- shrink-wrapping blocks ALL signals). Solution #3 would eliminate the
- need for recompilation, but you and Steve have expressed doubt about
- the feasibility of being able to programmatically detect these
- critical regions.
-
-
- Tom Payne (thp@cs.ucr.edu)
- ---
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
- is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
-